\documentclass{assn}
\num{Lab 2.2 Design Concerns}
\by{Ian Voysey (iev@), Ryan Hofler (rhofler@)}
\due{25 September 2008, 23:50}
\for{15-440: Fund. Systems}
\usepackage{float}
\usepackage{graphicx}

\begin{document}
This document outlines some of the high level design decisions that were made
in the development process of the single player game. To just simply roll out
a game that worked, we could have hacked everything together in a single class
and been alright, but this has several major problems with it:
\begin{itemize}
\item we would have received little or no credit for the lab
\item no abstraction boundaries between the different tasks inherent in
  running the game would have been enforced, introducing all of the classes of
  bugs and errors in debugging that OOP zealots preach about
\item proceeding to the multiplayer networked version would have demanded a
  massive refactoring of the code, which is both a royal pain and a sure-fire
  way to introduce nasty bugs
\item assuring some measure of robustness against malicious network clients in
  the future would have been possible, but less straight forward
\end{itemize}

\section{Class Structure}
The classes were structured with respect to strong work abstraction
habits. The process of parsing a board out of a text file is disjoint from the
rest of the game, so make it a class; the notion of storing a board is
disjoint from the rest of the game, make it a class; etc. This created the
typical Java-bloat due to semi-extraneous container packages, but thereby also
allowed us to use a larger subset of the slick Java built-ins. We did try to
mitigate the bloat in a few places---notably in the use of integer constants
to indicate much of the action happening with the \texttt{Items} and
\texttt{Tiles}.

\section{Package Structure}
Above the distinctions between different tasks and different encapsulated bits
of data, there's a larger abstraction distinction that we can make: trusted
game internals versus semi-trusted IO code. There's no reason at all that
the IO class ought to ever be able to call \texttt{Board.setTile()}, but it
greatly simplifies the life of the board parser if it can. By placing these in
different packages, we not only cleaned up the boundaries around each class,
we created the ability to use \texttt{protected} status meaningfully.

In the next stage, this boundary is likely to be extended even further: the
trusted internals code will form a server, and the semi-trusted IO code will
mature into fully untrusted client code. These packages will probably become
separated applications entirely, running on different hardware, but, due to
their corralled origins, the transition will be less painful.

\section{A Couple of Hacks}
By trying to make as much of this code live through the change to networked
multiplay as possible, we ended up over engineering things in a couple
places. The single player is often stored in a one-element
\texttt{ArrayList}. 

Another such hack is having the IO class initialize the engine. This will be
replaced with searching for a server in the next version, but this was more
sane when everything was local.
\end{document}
